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REMARKS/ARGUMENTS 

In Section 2 of the Office Action mailed on November 1 8, 2004, the Examiner 
objected to the drawings. A substitute set of formal drawings in compliance with MPEP 
608.02(g) and 37 C.F.R.§ 1. 121(d) with a transmittal letter is submitted herewith. 

In section 4 of the Office action, the Examiner objected to the disclosure as 
containing an embedded hyperlink. By the amendment to the specification above the reference 
to the hyperlink is deleted. 

In sections 5 to 7, the Examiner objected to claim 10, 20, 21, 48, and 51 for 
different informalities. Applicants thank the Examiner for his comments and the appropriate 
amendments have been made as suggested by the Examiner. 

In sections 10 to 14, the Examiner rejected Clams 15-16, 27, 33, 34 and 41 under 
35 U.S.C. 112. Applicants thank the Examiner for his comments and by this response 
respectfiilly submit the following amendments which are believed to be sufficient to 
overcome the above rejections. In making these revisions care has been taken to ensure that 
no new matter has been added. 

1. Claim 15 has been amended in accordance with the Examiner's proposal, thereby 
also overcoming the rejection of Claim 16. 

2. Claim 27 has been amended to be dependent on Claim 26, thereby providing 
adequate antecedent basis for the use of term "said testing" in Claim 27. 

3. Claim 3 1 has been amended to recite the term "existential charts" (using language 
taken fi"om Claim 32), and therefore it provides adequate antecedent basis for the use 
of term "the existential charts" in Claim 33 (dependent upon Claim 31). 

4. Claim 22 has been amended to recite the term LSC, thereby providing adequate 
antecedent basis for the use of term "said LSC" in Claim 34. 

5. Claim 41 has been amended in accordance with the Examiner's suggestion. 

Examiner rejected Clams 1-9, 12, 14-16, 18-21, 24, 26, 28, 30-33 and 35-51 under 35 
U.S.C. 102(e) as anticipated by U.S. 6,205,575 to Sherman ('575 ). Applicants amended 
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independent Claims 1,19 and 39 to clarify the subject matter of the application. In making 
these revisions care has been taken to ensure that no new matter has been added. 

Applicants appreciate the time and consideration provided by the Examiner in reviewing 
this application, however, respectfully traverse the rejections of the claims at least for the 
following reasons. 

Rejection under 35 U.S,C,§102(b) 

Anticipation under 35 U.S. C. § 1 02 requires that each and every claimed feature be 
disclosed by a single prior art reference 

In order to provide a better understanding of the subject matter of the present 
application. Applicants present herewith a brief overview of the underlying concept in 
accordance with certain embodiments as described in the application. The Object oriented 
modeling (OOAD - Object Oriented Analysis and Design) started to show up in the late 
1980's and has been used to "lift" concepts from the programming language. Referring to the 
system behavior, there are known in the art two aspects that have to be modeled, the intra- 
object behavior, which describes the way each one of the instances behaves, and the inter- 
object behavior, which describes the interaction between the objects in different possible 
scenarios of the system. 

Statecharts language and message sequence charts (MSCs) are known tools to describe 
system behavior (page 1, lines 1-5 of "Background of the invention" section of the present 
application). Use cases were introduced in order to describe the system by identifying the 
different observable behaviors and interactions of the system with the user (page 1 , line 23 to 
page 2, line 2 of "Background of the invention" section of the present application ). A more 
advanced extensive expansion of the system behavior specification language of MSCs is live 
sequence charts (LSCs). (page 2, line 30 to page 3 of the present application). 

These known solutions do not allow a fully automated procedure as shown in Fig. 1 and 
page 4, lines 7 to 1 0 of the application, illustrating the manual and tedious effort requiring to 
"translate" fi-om use cases representation to system requirement level (say in LSC form). 

Accordingly, let's consider a typical application such as designing Rapid Prototype 
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and/or Simulation Tools. The use of Prototypes/simulation tool is normally required before 
building a new system. For designing the system behavior of the prototype, it would be highly 
desired to define the prototype system behavior in a convenient manner. In the context of 
prior art solutions this is not achievable since the system designer is compelled to go through 
the cumbersome and tedious procedure using the known per se formal system behavior 
languages, all as discussed above with reference to the prior art. It readily arises that in 
accordance with the teachings of the prior art, the system designer cannot define system 
behavior by interacting intuitively with the system prototype's GUI. More specifically, the 
user is required to design manually in high level, say using "use cases*' describing system 
behavior (in high level representation) and reduce manually through tedious manual work the 
high level representation into more formal system behavior representation (such as the LSC). 
Not only the designer is compelled to lengthy and tedious manual work, but also he must have 
fairly good knowledge of the formal system behavior language. 

The present application, in accordance with certain embodiments thereof, clears this gap 
by allowing the designer to define a system graphic user interface (GUI) having at least a part 
which represent the real-world GUI of the designed system (see element (i) of Claim 1 as 
amended). A non limiting example of such GUI is a calculator, which includes representation 
of real-world calculator's user interface, described with reference to Figs. 4 to 24 including 
GUI objects, such as keys, etc. (see e.g. page 7, lines 30 to 32). The user "plays in" intuitively 
scenarios of interest by using objects of the GUI (which resembles the real-world interface of 
the system of interest), and gets system feedback by specifying the system reaction in response 
to using the system objects (amended element (ii) of Claim 1). The usage of the objects and 
system reaction (such as keys in the calculator and the resulted display) is exemplified in 
detail in the calculator example of Figs. 4 to 24. The system then substantially automatically 
constructs the formal system behavior specification, (elements (iii) of amended Claim 1), 
exempting the user fi-om having high level of expertise in the formal system behavior 
language. 
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The automatic construction of LSC charts (as recited in amended element (iii) of 
Claim 1) is illustrated for instance in the LSC charts of Figs. 4 to 24 (see also page 9, lines 7 
to 9). 

Note that in accordance with certain embodiments, the GUI may include additional 
objects such as internal components, etc. 

The advantage discussed above (in accordance with certain embodiments of the 
invention) is referred to also in page 1 7, lines 8 to 17. 

In contrast, Sherman in '575 discloses a system for facilitating definition, maintenance 
and presentation of scenarios. The system of Sherman facilitates selection of elements from 
system description in accordance with pre-defined syntax ( Abstract, Col. 6 lines 45-50). The 
system description of Sherman is defined in "low-level manner" requiring fairly extensive 
knowledge of the user in the system description syntax. As readily arises fi*om Col. 3, lines 6- 
28, 38-47 and Col. 7, lines 50-62, Shemian refers to the Flow diagrams. As is well known. 
Flow diagram is a shortcut for Data flow diagram (Bubbles representing the activities, objects 
and flow in a system, etc.). This is a design model that falls imder the category of low level 
representation requiring high level of expertise fi*om the system designer's end. 

Note incidentally that to the extent that Sherman refers to "use cases" indicating 
higher level representation of the system (see, e.g. Col 5. lines 18-23), Sherman refers to the 
"use cases" in a conventional and known per se manner. Thus, Sherman refers to the known 
publications in Col. 5, lines 23-28 and does not suggest any "automatic" manner for 
translating fi-om the use case representation into the "low level" formal system behavior 
specification and accordingly the "translation", if any, firom the high level use case 
representation to the low level. The formal system behavior specification is done through 
manual and tedious procedure, all as discussed above. 

It goes without saying that Sherman does not anticipate even remotely (amongst the 
other) the use of system GUI for the purpose of defining system behavior as disclosed and 
claimed in the present application, and obviously the teachings of Sherman do not bring about 
the advantages of using the system GUI as described above. 
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In other words, the teachings of Sherman share common shortcomings with the prior 
art solutions discussed in the Background section of the specification, which, amongst the 
other, do not allow interaction through GUI that at least partially represent a real-world 
system GUI and similar to the known prior art requires rather extensive knowledge of the 
formal system behavior representation (in the case of Sherman, through data flow diagrams). 
In this respect Sherman teaches away firom the claimed invention. 
Applicants therefore respectively requests withdrawal of the rejection of Claim 1 under 
102(e). 

Claims 2-9, 1 1-16, 18, 37-38, 40, 43, 46, 49 directly or indirectly depend upon Claim 1, 
and should be deemed novel and non obvious over the cited prior art reference, inter alia for 
the reasons discussed with reference to Claim 1, above. 

Amended Claim 19, directed to apparatus, should be deemed novel and non obvious 
over the cited Sherman, inter alia for the reasons discussed with reference to Claim 1 , above. 

Reverting now to the present application, in accordance with one of the aspects of the 
invention, there is provided a plaving out scenario (or scenarios) using system GUI and 
system behavior specification. At least part of the results of the operation of play-out is 
reflected in the system GUI. The play-out (as distinguished from the play-in) is described in 
detail with reference to the non-limiting examples in page 33, line 10 to page 34, line 10, and 
is further exemplified with reference to a non-limiting example with reference to Fig. 25. As 
arises firom the description, the playing out includes executing scenarios. 

With respect to the dependent claim 14 that recites "play out", not only it is deemed 
novel and non obvious over the teachings of Sherman (for the reasons discussed above), but it 
is additionally distinguished fi*om Sherman in that the latter does not disclose even remotely 
the play out. The examiner referred to Col. 5: lines 17-27, however, the latter merely suggests 
that Sherman refers to "use cases" in a conventional manner (see Col. 5, lines 23 -28, where 
reference is made to conventional use cases publication). The Examiner further referred to 
Col. 14, lines 25 to 28 of Sherman. According to the teaching of this section, scenarios can be 
animated. Note, incidentally, that this feature is already known fi-om other prior art 
publications, e.g. there are tools that can show scenarios as diagrams (e.g., various MSC 
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editors). However, in contrast to the teachings of the prior art, the play out as recited in 
amended Claim 14, includes (amongst the other) executing the scenario(s) and reflecting in 
the system GUI at least part of the result of the operation of the played out scenario(s) which 
is well distinguished from mere animation. 

It is accordingly submitted that Sherman does not teach or suggest the play out element 
recited in Claim 14. 

Before turning to discus the Examiner's rejection of independent Claim 20, it is noted 
that amended Claim 20 includes the limitation of Claim 21 . On the merits, the Examiner' 
substantiated the rejection of Claim 20 on the reasons elaborated with reference to Claim 1, 
notwithstanding the fact that Claim 1 recited play in, which is well distinguished from the 
play out recited in Claim 20. As discussed above (with reference to Claim 1) the teachings of 
Sherman do not anticipate even remotely the plav-in procedure and a fortiori they do not 
anticipate even remotely the play-out procedure. 

Applicants therefore respectively request withdrawal of the rejection of Claim 20 under 
102(e). 

Amended independent Claim 39, directed to apparatus, should be deemed novel and 
non obvious over the cited Sherman, inter alia, for the reasons discussed with reference to 
Claim 20, above. 

Claims 23-28, 30-33, 35-36, 41,42, 44, 45, 47, 48, 50 and 51 directly or indirectly 
depend upon Claim 20 (or 39) , and should be deemed novel and non obvious over the cited 
prior art for the reasons discussed above with reference to Claim 1 . 

Rejection under 35 U,S.C.§103(a) 

Claims 10, 17, 22, 29 and 34 rejected under 35 U.S.C. 103(a) as unpatentable over 
Sherman (USPN 6,205,575) in view of Werner Dam and David Harel, and Claims 11,13, 23, 
25 and 27 over Sherman in view of Ladkin. 

Since all rejections under 35 U.S.C. 103(a) are based primarily on Sherman, the 
arguments presented above are also applicable to the 103 rejection. As stated in MPEP ' 
2142, in order to establish a prima facie case of obviousness, the references must teach or 
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suggest all the claimed limitations. Applicants maintain that dependent Claims 10, 11, 13, 17, 
22, 23, 25, 27, 29 and 34 should be deemed novel and non obvious over the cited references, 
inter alia^ for the reasons discussed with reference to their respective independent base 
Claims 1 and 20. 

Therefore, the cited prior art references, alone and in combination, clearly teach away 
from the present application. 

Applicants respectfully submit that all the pending claims as originally presented and 
amended by this response are allowable, and the application is now in condition for 
allowance, which allowance is earnestly solicited. 

The Commissioner is hereby authorized to charge any fees, which may be required in 
connection with this correspondence, to Deposit Accoimt No. 06-1 135. 



Respectfully submitted. 



FITCH, EVEN, TABIN & FLANNERY 



By: 




Kenneth H. Samples 
Registration No. 25,747 



Date: 7 
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120 South LaSalle Street, Suite 1600 
Chicago, IL 60603-3406 
Telephone: (312) 577-7000 
Facsimile: (312)577-7007 
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